This page last changed on Sep 27, 2006 by scytacki.

On this page maintaining external state means that state of the a pojo (plain old java object) is saved both in the pojo and outside of that object (external).

Some counter examples, to clarify useful external state.

  • XMLDecoder creates the real objects and sets propeties on those real objects. This is not maintaing external state. Sure the xml file itself is external but it isn't easy to parse/navigate without actually "executing" it. So the external state needs to easy to parse and navigate.
  • xstream also creates real objects and sets properties on those real objects. Its xml is easy to parse and navigate. But after the xml has been turned into object, it is not possible to change the xml and affect the objects. The only way to change the objects is to completely reload them after changing the xml. So the external state needs to remain connected to the objects generated from it.

Features

  • external state is easy to parse and navigate
  • external state can be changed at run time and objects generated from it can be affected.
  • instances of real objects do not need to be available to modify and navigate the external state.

Pros

  • state can be created, modified, and navigated in environments where objects can't be instanciated.
    • For example state that represents gui classes can be manipulated on a server that is headless
    • Speed and Size of navigation, creationg, and modification is improved because only the persistant properties need to be instanciated.
  • multiple instances of an object can be created from the same state and continue to be connected through the state
    • a collection of state objects represent a data graph on the screen, the user manipulates the data graph, the user generates an image of the data graph which has different dimensions than the one on the screen. To do this a new set of real objects can be created from the state objects, and be set to the appropriate dimensions.
  • Can provide external generic gui editors and views of the state objects. These are similar to xml editors, but changes to the objects can be immediately be visible.

Cons

  • Takes up more space in memory
  • Inorder to keep things synchronized you need to add listeners to the real objects, and the state objects.

Other features not dependent on existance of external state

  • proxy or delay loading of objects. If one object references another object it should be possible to only load the referenced object when it is needed. Otherwise the entire object tree needs to be loaded at once.
Document generated by Confluence on Jan 27, 2014 16:56